1. Field of the Invention
This invention relates to the field of data processing systems. More particularly, this invention relates to data processing systems in which register renaming is used.
2. Description of the Prior Art
It is known to provide data processing systems which incorporate register renaming mechanisms. In such systems, program instructions include register specifiers identifying particular architectural registers when viewed from a programmer's model point of view. In order to facilitate higher performance operation, such as, for example, support for out-of-order execution (either at issue or writeback) or long pipelines, it is known to utilize register renaming whereby a larger pool of physical registers are actually provided by the microprocessor than are present within the programmer's model view of the microprocessor. This larger pool of physical registers enables hazards such as write-after-write (WAW) hazards to be avoided. Thus, whilst a program instruction may specify a particular architectural register to be used, register renaming mechanisms within the processor map this to a physical register which can be different from the physical register to which another program instruction specifying the same architectural register is mapped. Thus, the execution of the two program instructions specifying the same architectural register may be facilitated by use of different physical registers within the processor. The register renaming mechanism of known systems keeps track of which physical registers have been mapped to which architectural registers, if appropriate, and the relative ordering of the program instructions within the original program flow so that the proper behaviour and processing results are ensured.
Whilst register renaming is a powerful technique for enabling higher performance operation, it brings with it many associated practical difficulties and complexities. When an architectural register is to be mapped to a physical register it is necessary to identify which of the physical registers is available to be used for such a mapping. It is relatively straight forward to avoid WAW hazards in such a selection by keeping track of which physical register holds the latest value for an architectural registers and not overwriting such a physical register. However, avoiding write after read (WAR) hazards is more difficult. Such WAR hazards arise when a physical register is overwritten with a value from an architectural registers due to a new mapping whilst the original value stored in that physical register has still to be read by a pending instruction. If such a WAR hazard arises, then the pending instruction will read an incorrect value from the physical register since the value it was properly to read will have been overwritten. The read can take place at various timings after issue and this makes tracking pending reads difficult.
Two basic solutions can be envisaged for such a problem. One solution is to merge information from all pipeline stages holding pending instructions to identify registers for those pending instructions that have not yet been read. This requires a combinatorial logic path decoding all unread registers from all pipeline stages after register renaming (including any as yet unissued instructions) to a structure such as a large bit field with an entry for each physical register. This bit field could then be used to identify physical registers available for remapping. This solution is disadvantageous both in terms of the gate count needed to support such a mechanism and the extra power consumption needed to operate such a mechanism.
Another possible approach is to associate a counter with each physical register with this counter being incremented each time the physical register is referenced (i.e. an instruction issued which will require it to be read) and then decremented when that physical register is actually read. Thus, the counter keeps a record of how many pending reads there are for each physical register and only physical registers for which there are no pending reads will be made available for mapping.
This solution again has significant practical disadvantages, such as it is difficult to fix a size for the counters to be used since this will effectively place a limit on the number of times a register can be requested consecutively for a read. The counter will also need to be able to deal with incrementing and decrementing the counter by a number that depends upon the number of read ports activated at the same time for the same physical register, i.e. the physical register bank may have multiple read ports and in any given read cycle a physical register may be subject to more than one read. Thus, whilst such an approach might seem superficially attractive, it again has the disadvantage of requiring significant gate count and complexity overhead with an associated disadvantageous increase in power consumption.